home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 5 / QRZ Ham Radio Callsign Database - Volume 5.iso / digests / tcp / 940230.txt < prev    next >
Encoding:
Internet Message Format  |  1994-11-13  |  5.2 KB
  1. Date: Sat, 15 Oct 94 04:30:01 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: List
  6. Subject: TCP-Group Digest V94 #230
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sat, 15 Oct 94       Volume 94 : Issue  230
  11.  
  12. Today's Topics:
  13.                         ARP grumbles (3 msgs)
  14.                              Unsubscirbe
  15.  
  16. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  17. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  18. Problems you can't solve otherwise to brian@ucsd.edu.
  19.  
  20. Archives of past issues of the TCP-Group Digest are available
  21. (by FTP only) from UCSD.Edu in directory "mailarchives".
  22.  
  23. We trust that readers are intelligent enough to realize that all text
  24. herein consists of personal comments and does not represent the official
  25. policies or positions of any party.  Your mileage may vary.  So there.
  26. ----------------------------------------------------------------------
  27.  
  28. Date: Fri, 14 Oct 1994 09:34:42 -0800 (PDT)
  29. From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
  30. Subject: ARP grumbles
  31.  
  32. Why doesn't the ARP cache code in JNOS (1.08):
  33.  
  34. 1. learn the hardware address from incoming packets.  it's pretty
  35.    silly to receive an incoming packet (say an ICMP echo request) then
  36.    turn around and broadcast an ARP request when the hardware address
  37.    is right under its nose
  38.  
  39. 2. why doesn't it reset the ARP cache timers when there are incoming
  40.    packets, instead of letting the timers run down, and have to
  41.    retransmit an ARP request. In other words, JNOS can hear a packet
  42.    a few ticks before the ARP timer runs down, but it doesn't reset the
  43.    timer, so it's forced to do a useless ARP request.
  44.  
  45. Life's bad enough at 1200bps, I'm going to add static ARP entries for
  46. the important hosts.
  47.  
  48.  
  49.  
  50. ---------------------------------------------------------------------------
  51. BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  -- 
  52. jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org
  53. ---------------------------------------------------------------------------
  54.  
  55. ------------------------------
  56.  
  57. Date: Fri, 14 Oct 1994 16:30:53 -0400
  58. From: "Louis A. Mamakos" <louie@alter.net>
  59. Subject: ARP grumbles 
  60.  
  61. > Why doesn't the ARP cache code in JNOS (1.08):
  62. > 
  63. > 1. learn the hardware address from incoming packets.  it's pretty
  64. >    silly to receive an incoming packet (say an ICMP echo request) then
  65. >    turn around and broadcast an ARP request when the hardware address
  66. >    is right under its nose
  67.  
  68. Because you don't know if the packet arrived from the source address
  69. in the packet or not.  It may be been forwarded from an intermediate
  70. router.
  71.  
  72. > 2. why doesn't it reset the ARP cache timers when there are incoming
  73. >    packets, instead of letting the timers run down, and have to
  74. >    retransmit an ARP request. In other words, JNOS can hear a packet
  75. >    a few ticks before the ARP timer runs down, but it doesn't reset the
  76. >    timer, so it's forced to do a useless ARP request.
  77.  
  78. For the same reason above.  You don't know what arp entry it's associated
  79. with, especially if you play proxy ARP games.  ARP caches are not usually
  80. designed to be searched in that direction, either.  
  81.  
  82. > Life's bad enough at 1200bps, I'm going to add static ARP entries for
  83. > the important hosts.
  84.  
  85. Oh well.  You could us a V.32bis modem on a dial-up connection and get
  86. better throughput until we get better radios and modems.
  87.  
  88. louie
  89. wa3ymh
  90.  
  91. ------------------------------
  92.  
  93. Date: Fri, 14 Oct 1994 11:45:18 -1000 (HST)
  94. From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
  95. Subject: ARP grumbles
  96.  
  97. On Fri, 14 Oct 1994, John Paul Morrison wrote:
  98. > Why doesn't the ARP cache code in JNOS (1.08):
  99. > 
  100. > 1. learn the hardware address from incoming packets.  it's pretty
  101. >    silly to receive an incoming packet (say an ICMP echo request) then
  102. >    turn around and broadcast an ARP request when the hardware address
  103. >    is right under its nose
  104.  
  105. There is a limited 'arp eavesdrop' feature in the latest versions of JNOS. 
  106. But to blindly map every incoming IP address to an ARP entry isn't wise. 
  107. Suppose you were the only host on a net talking to a single default
  108. router.  Now suppose you had several dozen other hosts connecting to you
  109. all through that router.  Do you create several dozen ARP entries?  At 
  110. what point does the IP routing table became useless and NOS becomes a 
  111. bridge rather than a router?  Suppose instead of several dozen hosts 
  112. connecting to you it was several thousand over a period of days or weeks?
  113.  
  114. > 2. why doesn't it reset the ARP cache timers when there are incoming
  115. >    packets, instead of letting the timers run down, and have to
  116. >    retransmit an ARP request. In other words, JNOS can hear a packet
  117. >    a few ticks before the ARP timer runs down, but it doesn't reset the
  118. >    timer, so it's forced to do a useless ARP request.
  119.  
  120. The 'arp eavesdrop' feature does this for you.  But remember that it 
  121. depends on arp responses heard on the net to reset timers.
  122.  
  123. Antonio Querubin  
  124. tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org
  125.  
  126. ------------------------------
  127.  
  128. Date: Fri, 14 Oct 1994 19:36:00 -0400 (EDT)
  129. From: Admin <uunet!k4ngc!root>
  130. Subject: Unsubscirbe
  131.  
  132. unscribe
  133.  
  134. ------------------------------
  135.  
  136. End of TCP-Group Digest V94 #230
  137. ******************************
  138.